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ABSTRACT 


The  Initial  Graphics  Exchange  Specification 
(IGES)  was  first  developed  in  1980.  it  has 
evolved  with  continual  improvements  to  the 
current  version  5.1  which  was  published  in 
October,  1991  (I). 

Although  IGES  has  proved  to  be  a  very 
valuable  tool,  difficulties  have  been  encountered 
in  using  it  for  sophisticated  transfers,  such  as  for 
product  models  or  complicated  drawings.  The 
primary  problems  have  revolved  around  the  fact 
that  the  specification  allows  for  multiple  forms  of 
representing  the  same  data,  which  results  in 
difficulties  in  transferring  that  data  between 
varied  CAD  (Computer  Aided  Design)  systems. 

The  long  range  solulion  to  these  difficulties  is 
the  emergence  or  STISl’  (Standard  for  the 
Exchange  of  Product  Model  Data).  The 
Navy/industry  Digital  Data  Exchange  Standards 
Committee  (NIDDRSC)  has  been  a  leading  player 
in  the  development  of  this  international  standard. 
However,  in  the  interim,  NIDDESC  is  also 
spcarchcading  the  efforts  to  enhance  the  use  of 
IGES  by  developing  application  protocols. 

Application  protocols  are  required  because 
IGES  allows  for  multiple  ways  of  representing  the 
same  data,  and  few  implementations  support  all  of 
the  IGES  Specification.  An  application  protocol 
defines  a  logical  subschema  of  the  specification, 
and  describes  the  usage  of  that  subschema  as  well 
as  the  necessary  benchmarks  for  testing 
implementations 

NIDDESC  has  led  the  efforts  to  develop  IGES 
application  protocols  for  3D  Piping  and 
Engineering  Drawings.  These  two  application 
protocols  arc  the  first  ones  to  be  developed  by  the 
IGES/PDES  (Product  Data  Exchange  using  STEP) 
Organization  (I.P.O.),  and  will  lead  the  way  to 
more  productive  data  transfer  before  the 


development  Of  STEP’.  They  will  be  referenced 
by  the  DoD  (United  States  Department  of  Defense 
standard  for  digital  data  transfer. 
MIL-D-28000(2),  and  should  greatly  facilitate  the 
occurrence  of  effective  data  transfer  in  these  two 
disciplines.  Eurthermore,  the  use  of  these  IGES 
application  protocols  is  expected  to  provide 
significant  guidance  in  the  development  of 
application  protocols  for  the  emerging  STEP 
standard. 

This  article  will  focus  on  the  development  o; 
these  two  application  protocols,  the  involvement 
of  NIDDESC  and  the  shipbuilding  industry  (a; 
well  as  the  participation  of  other  industry  users 
and  vendors),  and  the  significant  benefits  to  be 
derived  from  the  adoption  of  these  standards. 


NOMENCLATURE 

A  EC  =Architecture,  Engineering,  and 
Construction  Committee 

-  Committee  of  the  IGES/PDES 

Organization  through  which  NIDDESC 
efforts  are  submitted 

AP  =  A  ppii cation  Protocoi 

A  specification  for  representing  product 
model  data  from  an  application  area  in  the 
format  of  a  given  data  exchange  standard 

AVM  =  Application  Validation  Methodology 
Committee 

-  Committee  of  the  IGES/PDES 

ORGANIZATION  which  sets  criterion  for  and 
approves  format  of  application  protocols 

CAD  =Compi/ter  Aided  Des/gn 

Describes  computer  methods  and  symbols 
used  in  the  design  process 
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CALS  =  Computer-aided  Acquisition  and  Logistic- 
Support 

Program  of  the  Office  of  the  Secretary  of 
Defense 

Objective  is  to  establish  an  integrated  set  of 
standards  and  specifications  for  the 
creation,  management,  and  exchange  of 
product  development  and  logistic  data  by 
computer 

DoD  =  United  States  Department  of  Defense 

Issuing  organization  for  MIL-D-28000  to 
specify  standards  for  digital  data  exchange 

DoE'  =  United  States  Department  of  Energy 

-  Developed  an  IGES  based  plan  for 

exchanging  drawings  among  its  own  sites 

DOEDEF  =  Department  of  Energy  Data 
Exchange  Format 

Project  to  establish  rules  and  guidelines  to 
enable  production  drawing  exchange 
within  the  DoE 

IGES  =  Initial  Graphics  Exchange  Specfication 

First  developed  in  1980 

Currently  in  widespread  use  in  American 

industry 

-  Primarily  designed  to  transfer  graphics 

between  existing  CAD  systems 

I.  P.  0.  =  IGESlPDES  Organization 

-  United  States  committee  that  publishes 

IGES  Specification  and  is  coordinating 
U.S.  effort  toward  development  of  STEP 

/.  S.  0.  =  International  Standards  Organization 

Parent  organization  of  committee  that  is 
developing  STEP  Standard 

MIL-D-28000  =  DoD  Specification  for  Digital 
Data  Exchange 

-  References  the  3D  Piping  IGES 

Application  Protocol  as  Class  V 
Eventually  plans  to  supplement  Class  II 
with  the  Engineering  Drawings  IGES 
Application  Protocol 

NIDDESC=Navy  Industry  Digital  Data  Exchange 
Standards  Committee 

-  Joint,  cooperative  effort  of  Navy  and 

industry  to  develop  data  exchange 
standards  and  procedures  for  use  in  the 
shipbuilding  industry 

PDES  =  Product  Data  Exchange  using  STEP 

-  Unites  States  effort  in  support  of 

development  of  STEP  Standard 


SEA  WOLF  =  SSN2  I 

New  Class  of  submarine  being  developed 
for  the  United  States  Navy  by  Newpon 
News  Shipbuilding  and  General 
Dynnamics/Electric  Boal  Division,  whose 
design  and  construction  have  pioneered  in 
the  production  use  of  electronic  data 
exchange 

STEP  =  Standard  for  the  Exchange  of  Product 
Model  Data 

-  Proposed  international  standard  for  the 

exchange  of  product  models 

Version  1  is  currently  in  I.S.O.  balloting 

process 

Current  version  is  very  restricted  in  scope 
and  will  be  of  limited  use  in  man;, 
application  areas 

-  It  will  be  years  before  STEP  is  in 

widespread  production  use 

INTRODUCTION 

General  use  of  IGES 

The  importance  and  benefits  of  electronic  data 
exchange  have  long  been  recognized,  and  the 
difficulty  of  developing  and  maintaining  direct 
translators  between  CAD  systems  led  to  the 
concept  of  a  neutral  file  transfer,  and  the 
subsequent  development  of  the  Initial  Graphics 
Exchange  Specification  (I)  with  Version  I  being 
published  in  1980. 

In  the  last  decade,  IGES  has  been  expanded  and 
improved  greatly  with  Version  5.1  being 
published  in  October,  1991.  Despite  the  expansion 
in  the  scope  of  IGES  (for  instance,  it  now  includes 
solid  geometry  and  attribute  table 
representations),  and  its  vast  improvement  in 
recent  years,  there  arc  still  many  organization., 
that  have  had  difficulties  in  using  the  specification 
to  successfully  accomplish  digital  data  transfer. 

One  problem  frequently  encountered,  is  that 
because  of  the  breadth  of  the  IGES  Specification, 
there  may  be  several  correct  ways  to  represent 
certain  entities  from  a  CAD  system,  and  an 
exchange  will  only  be  successful  if  both  systems 
choose  to  use  the  same  implementations. 
Documents  such  as  the  “IGES  5.1  Recommended 
Practices  Guide  ”  (3)  have  helped  reduce  these 
problems  by  giving  guidelines  for  the  best  way  lO 
implement  the  specification  in  certain  instances. 
However,  to  insure  the  best  possible  transfer 
between  diverse  CAD  systems,  the  IGES 
processors  must  be  written  lo  conform  to  a  much 
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more  rigid  set  of  requirements.  It  is  this  lightly 
controlled  environment  (which  will  lead  to 
successful  and  productive  digital  data  transfers) 
that  the  development  of  application  protocols  is 
designed  to  create. 

Snocitic  Proiecls 

Aside  from  the  general  attempts  to  use  IGES 
successfully.  Severall  organizations  or  projects 
have  developed  task  forces  or  working  groups  to 
use  IGES  to  implement  their  specific  data 
exchange  requirements. 

The  Navy/ Industry  Digital  Data  Exchange 
Standards  Committee  (NIDDESC)  was  formed  in 
1986  as  a  joint  cooperative  effort  between  the 
Navy  and  corporate  participants  from  the 
shipbuilding  industry  because  of  the  realization  as 
to  how  valuable  effective  electronic  data  exchange 
could  be  to  the  marine  industry.  It  is  largely 
because  of  the  efforts  of  NIDDESC  and  its 
member  companies  that  the  application  protocol 
development  projects  discussed  in  this  article  wore 
Undertaken 

The  SEAWOLF  Digital  Data  Exchange  project 
provides  another  example  of  the  successful  use  of 
IGES  for  exchanging  data.  This  project  was  a  joint 
effort  of  NAVSEA,  General  Dynamics/Electric 
Boat  Division^  and  Newport  News  Shipbuilding 
and  used  TGBS  successfully  to  transfe- 
engineering  drawings  as  well  as  structural  and 
piping  models.  In  fact,  the  SEAWOLF  piping 
Product  Model  transfer  provided  the  basis  for  the 
development  of  the  3D  Piping  IGES  Application 
Protocol  (4) .  A  more  detailed  description  of  the 
SEAWOLF  Digital  Data  Exchange  Project  is 
available  in  Reference  5. 

The  DOEDEE  Project  of  the  U.  S.  Department 
of  Energy  (DOE)  successfully  set  Up  rules  and 
standard  format  for  the  transfer  of'  drawings  via 
IGBS  among  many  DoE  sites  using  different  CAD 
systems. 

The  success  of  these  project  specific 
implementations  demonstrates  that  digital  data 
exchange  using  IGES  can  be  productive  in  today's 
environment  when  the  scope,  formats,  and 
implementation  of  the  transfers  arc  rigidly 
controlled.  These  experiences  have  led  to  creation 
of  the  concept  of  IGES  application  protocols,  and 
their  development  and  implementation  through 
efforts  led  by  NIDDESC. 

Throughout  this  article  mention  is  made  of 


several  Organizations  and  Specification.  The 
IGES/PDES  Organization  (I.P.O.)  is  a  body 
composed  of  volunteers  from  industry  and 
government  agencies  (primarily  in  the  United 
States)  who  have  developed  the  IGES  Specification 
and  are  participating  in  the  development  of  STEP' 
under  the  auspices  of  the  International  Standards 
Organization  (I.S.O.).  IGES  has  been  primarily 
used  to  transfer  graphics  data  between  existing 
CAD  systems.  STEP  is  being  developed  to 
provide  an  international  standard  for  the  exchange 
of  product  models. 

NIDDESC  is  a  joint  cooperative  effort  of  the 
U.  S.  Navy  and  the  marine  industry  to  develop 
data  exchange  standards  and  procedures  for  use  in 
the  shipbuilding  industry.  NIDDESC  participates 
actively  in  the  I.P.O.  and  is  making  major 
contributions  to  both  the  IGES  and  STEP 
standards. 

Ail  of  these  activities  fail  under  the  umbrella  of 
the  Computer-aided  Acquisition  and  Logist; : 
Support  (CALS)  Program  of  the  United  States 
Department  of  defense,  and  arc  heavily  supported 
and  enthusiastically  endorsed  by  the  government  . 

APPLICATION  PROTOCOLS  -  CONCEPT 

AND  IMPLEMENTATION 

Background 


The  Initial  Graphics  Exchange  Specification 
(IGES)  was  first  developed  in  1980  as  a  neutral 
file  format  to  facilitate  digital  data  transfer 
between  CAD  systems  existing  at  that  time. 
Despite  the  extensive  efforts  that  went  into 
developing  the  specification,  many  attempted  data 
transfers  wer  unsuccessful  or  encountered 
problems,  especially  in  the  first  few  years  of  the 
standard. 

Some  of  the  problems  were  caused  by  the  IGIB 
Specification  not  having  an  adequate 
representation  for  all  constructs  within  a  CAD 
system.  These  were  addressed  in  later  versions  01 
the  standard,  and  ongoing  enhancements  arc  still 
underway 

More  difficulties,  however,  were  caused  by 
opposite  problems:  that  IGES  allowed  multiple 
correct  representations  of  the  same  information, 
and  that  vendors  would  each  implement  a  unique 
subset  of  the  specification.  Additional 
complications  were  caused  by  the  lack  of 
validations  procedures  for  translators  and  the 
translation  process. 


5B2-3 


It  is  the  above  class  of  problems  that  the 
concept  of  an  application  protocol  was  designed  to 
solve. 

Structure  of  an  Application  Protocol  (Ap 

The  basic  problem  in  digital  information 
exchanges  can  be  expressed  as  agreeing  on  the 
meaning  and  purpose  of  exchange  data.  The 
resolution  of  this  problem  is  achieved  by 
providing  the  methods  for  developing,  testing,  and 
implementing  information  models  that  define 
unambiguous  sets  of  data  elements. 


Application  protocols  are  the  means  to  this 
solution.  They  provide  a  method  to  achieve 
consistent  and  reliable  exchange  of  product  data 
within  a  specified  application  area.  The  key 
concept  is  to  explicitly  link  the  application’s 
information  content  to  the  entities  and  data 
structures  to  be  exchanged.  An  AP  defines  the 
context  for  the  use  of  product  data,  and  specifics 
the  use  of  the  standard  (i.c.  IGES)  in  that  context 
to  satisfy  an  industrial  need. 

There  arc  four  key  components  to  an 
application  protocol: 

1)  Application  Scope  and  Requirements 

-  defines  the  realm  and  applicability 
of  the  type  of  data  to  be  exchanged; 

2)  Application  Reference  Model  (ARM) 

-  defines  the  supported  information 
and  application  domain  in  an 
information  modelling  language  that 
is  independent  of  the  specific 
transfer  specification  being  used; 

3)  Application  Interpreted  Model(AIM) 

-  specifies  the  data  constructs  used  fog 
rpresenting  the  application 
information  defined  in  the  ARM  in 
the  selected  neutral  file  format  (i.c. 
IGES);  and 

4)  Conformance  Criteria  and  Test 
Purposes  -  specifies  conformance 
testing  to  increase  the  confidence  that 
different  implementations  of  the  AP 
will  be  able  to  exchange  information 
successfully. 

A  more  detailed  description  of  the  structure 
and  requirements  for  an  IGES  application 
protocol  is  available  in  the  “Guidelines  for  tl:P 
Specification  and  Validation  of  IGES  Application 
Protocols”,  by  R.  Harrison  and  M.  Palmer  (6). 


Implementation  Efforts 


The  STEP  Standard,  which  is  being  developed 
as  an  international  specification  for  the  exchange 
of  product  model  data,  will  depend  heavily  upon 
application  protocols  basis  for  its  successful 
implementations.  However,  in  the  interim  period 
until  STEP  is  an  approved  international  standard 
with  production  translators  to  support  it  it.  there  is  a 
need  for  IGES  application  protocols. 

The  urgent  need  for  application  protocols  and 
the  extensive  time  required  for  STEP  to  become  a 
workable  standard  has  caused  NIDDESC  lo  lead 
development  efforts  for  two  IGES  application 
protocols:  one  for  three  dimensional  (31))  Piping, 
and  the  other  for  Engineering  Drawings.  Along 
with  the  extensive  marine  industry  participation, 
the  AP  ’efforts  have  received  significant  help  lion: 
CAD  vendors  and  members  of  process  plant  and 
other  industries.  This  voluntary  participation 
demonstrations  the  wide  spread  need  for  these 
documents. 

THE  3D  PIPING  IGES  API’LICATION 
PROTOCOL 

Background  of  the  Piping  AP 

The  3D  Piping  IGES  Application  Protocol 
represents  an  attempt  to  use  IGES  in  ways  that  arc 
beyond  the  original  scope  of  the  specification) 
Whereas  IGES  was  primarily  designed  to  enable 
the  transfer  of  graphical  data  as  it  is  captured  oil 
current  CAD  systems,  the  Piping  AP  is  using 
IGES  to  transfer  product  model  information.  To 
facilitate  this  use  of  IGES,  several  enhancements 
were  required  to  the  specification  in  order  to 
support  the  piping  model  transfer, 
enhancements  were  approved  by  thel.P.O..  and 
arc  included  in  Version  5.1  of  the  IGES 
specifications!  1) 

The  scope  of  the  3D  Piping  IGES  Application 
Protocol  is  discussed  in  the  abstract  of  the. 
document  itself  (4).  As  explained  there: 

“The  3D  Piping  IGES  Application  Protocol 
(AP)  specifies  the  mechanisms  for  declining  and 
exchanging  3D  piping  system  models  in  IGES 
format.  The  AP  defines  three-dimensional 
arrangement  data  of  piping  systems  which 
includes  definition  data  types  of  geometry 
(shape  and  location),  connectivity,  and  material 
characteristics.  The  scope  of  this  AT  includes 
only  piping  System  and  1101  drawings  or 
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internal  details  of  equipment.  The  specified 
piping  model  is  sufficiently  detailed  to  supper: 
the  fabrication  and  final  assembly  of  a  piping 
system. 

IGES  is  designed  to  support  a  broad  range  of 
applications  and  information,  and  it  is 
recognized  that  few  implementations  wil! 
support  all  of  the  specification.  An  application 
protocol  defines  a  logical  subschema  of  the 
IGES  Specification,  the  usage  of  the 
subschema,  and  the  necessary  benchmarks  for 
testing  implementations. 

The  3D  Piping  IGES  Application  Protocol  is 
the  first  IGES  AP  to  be  delivered  to  industry 
and  is  an  important  example  for  the 
development  of  STEP  (Standard  for  the 
Exchange  of  Product  Model  Data)  application 
protocols." 

Historical  Perspective  on  Development 
Efforts  in  Pining  Data  Transfer 

Discussions  about  using  IGES  to  transfer 
piping  product  model  data  began  in  the 
IGES/PDES  Organization' s  AEG  Committee  in 
the  mid-1980s.  These  led  to  the  incorporation  of  a 
3D  Piping  Example  as  an  appendix  to  IGES 
Version  4.0.  The  AEG  Committee  also 
participated  in  development  of  a  Distribution 
Systems  Model.  The  IGES  example  was  a 
forerunner  of  the  SEAWOLF  Piping  Data 
Exchange  Procedure  and  the  3D  Piping  IGES 
Application  Protocol,  while  the  Distribution 
Systems  Model  was  a  pre-cursor  to  the  STEP 
Piping  Application  Protocol  (being  developed  by 
NIDDESC)  as  well  as  the  ARM  used  in  the  31) 
Piping  IGES  AP. 

The  real  impetus  for  a  3D  Piping  IGES 
Application  Protocol,  however,  came  from  the 
SEAWOLF  Digital  Data  Exchange  Project.  This 
new  class  of  submarine  is  being  jointly  designed 
for  the  U.  S.  Navy  at  Newport  News  Shipbuilding 
and  General  Dynamics/Electric  Boat  Division 
with  the  potential  for  construction  at  both 
shipyards.  The  SEAWOLF  Piping  Data  Exchange 
Procedure  was  developed  in  a  cooperative  effort 
between  Newport  News  Shipbuilding,  Electric 
Boat  Division  and  NAVSEA,  and  was  designed  to 
use  an  IGES  neutral  file  format  to  transfer  piping 
product  model  information  between  Newport 
News'  VTVTD'  system,  and  Electric  Boat 
Division's  PIPER  system.  Both  of  these  were, 
in-house  developed  CAD  systems  that  were  being 
used  to  support  SEAWOLF  piping  design  and 
fabrication.  Most  of  the  IGES  constructs  that 
were  later  used  in  the  31)  Piping  IGES  AI'  were 


first  implemented  in  translators  developed  for 
SEAWOLF  Piping  Data  Exchange. 

The  formal  project  to  develop  the  3D  Piping 
IGES  Application  Protocol  was  sponsored  by 
NIDDESC,  although  it  also  had  significant 
participation  from  members  of  the  process  plant 
industry  as  well  as  the  vendor  community. 

Version  1  .0  was  published  in  October,  1990 
and  underwent  extensive  review  within  the  IGES 
community.  Version  1  .1  was  formally  published 
in  March,  1992  and  incorporates  changes  designed 
to  resolve  the  comments  against  Version  I  .0.  The 
March,  1992  version  of  the  document  is  the  one 
being  referenced  by  MIL-D-28000,  and  the  one 
that  is  being  submitted  to  the  I.  P.  0.  for  approval 
and  inclusion  in  the  next  version  of  the  IGES 
Specification. 

This  extensive  review  process  has  insured  that 
the  3D  Piping  IGES  Application  Protocol  is  not  i 
shipbuilding  or  NIDDESC  solution,  but  instead 
represents  a  consensus  agreement  among  several 
industries  of  a  viable  way  to  transfer  piping 
product  model  data  in  today's  environment. 

Version  1.1  of  the  Pining  AP 

The  scope  of  the  3D  Piping  IGES  AP  is  the 
exchange  of  3D  piping  models  at  a  level  of  detai' 
sufficient  to  support  fabrication  and  assembly  of 
piping  systems.  In  this  case,  a  3D  model  consist, 
only  of  piping  system  data.  Specifically  excluded 
are  other  types  of  systems  that  arc  similarly 
modelled,  i.e.  structural  steel  and  concrete.  I  IVAC 
(heating,  ventilation,  and  air  conditioning),  art' 
electrical  cable  tray  and  conduit  systems. 

This  application  protocol  defines  a  core  01 
required  data  which  supports  a  corresponding  set 
of  piping-related  activities.  These  activities 
include: 

1)  interference  analyses 

2)  connectivity  checks, 

3)  basic  parts  lists, 

4)  graphic  presentations 

5)  basic  piping  isometrics. 

6)  pipe  bending  instructions,  and 

7)  limited  piping  redesign. 


VIVID® is  a  registered  trademark  of  Newport 
News  Shipbuilding. 
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The  implication  is  that  the  model  transferred 
will  include  enough  information  to  support  each 
of  these  applications  on  the  receiving  system,  not 
that  the  end  products  are  exchanged.  For  instance, 
"basic  piping  isometrics"  means  that  the  receiving 
system  has  enough  information  to  generate  an 
isometric  drawing  in  its  own  format,  not  that  the 
actual  drawing  is  transferred. 

The  Attribute  Table  Entity  in  the  IGES 
Specification  was  expanded  to  support  the  core 
attributes  in  the  piping  AP,  as  well  as  to  include 
many  other  properties  that  are  not  reguired  by  the 
application  protocol.  This  allows  the  functionality 
of  the  core  data  to  be  extended  by  agreements 
between  the  sender  and  receiver  of  the  data. 

The  unique  feature  of  this  protocol  is  its 
attempt  to  use  IGES  to  transfer  data  describing  a 
complete  product  model,  rather  than  just  the 
graphical  data  associated  with  that  model.  It  thus 
requires  the  sending  and  receiving  systems  to 
make  specific  interpretations  of  IGES  entities. 
Eor  instance,  a  pipe  is  not  represented  by  a  solid 
model  of  cylinders  and  toroids,  but  instead  has  its 
'centerline  represented  by  an  IGES  Composite 
Curve  Entity.  The  pipe  diameter  (and  other 
properties)  are  referenced  in  the  IGES  file  by  a 
pointer  to  an  Attribute  Table  Instance  Entity. 

In  a  similar  manner,  the  Piping  AP  identifies 
many  piping  occurrences  by  special 
interpretations  of  various  IGES  entities.  For 
example,  a  piping  joint  is  represented  by  a  null 
composite  curve  consisting  of  only  two  Connect 
Point  Entities.  The  Composite  Curve  Entity  will, 
in  turn,  point  to  an  Attribute  Table  Instance  Entit! 
to  specify  the  properties  of  that  joint. 

The  fact  that  this  AP  requires  specific 
interpretations  of  IGES  entities  means  that  a 
general  purpose  IGES  translator  may  not  support 
this  protocol.  A  company  may  need  to  modify  its 
translator  or  write  a  new  one  in  order  to  comply 
with  the  AP.  However,  the  use  of  the  3D  Piping 
IGES  Application  Protocol  will  enable  the 
transfer  of  a  far  richer  set  of  piping  product 
model  data  than  merely  using  IGES  as  a  graphical 
transfer  mechanism. 

Version  1.1  of  the  3D  Piping  IGES  AP  was 
formally  issued  in  March,  1992.  It  has  been 
extensively  reviewed  within  the  IGES/PDES 
Organization,  and  has  been  approved  by  the  I.  P. 
O's  ABC  and  AVM  Committees. 

Validation  testing  of  the  application  protocol  is 
currently  underway  at  the  David  Taylor  Research 


Center.  Upon  completion  of  this  testing,  the  AP' 
will  be  submitted  to  the  IGES  Project  Committee 
and  then  the  I.  P.  0.  Genera!  Assembly  for 
approval  and  inclusion  in  the  next  version  of  the 
IGES  Specification.  This  will  be  the  first  IGES 
application  protocol  to  be  submitted  to  the  I.  I'.  0. 
formal  approval  and  is  also  the  version 
referenced  in  MIL-D-28000. 

Version  2  of  the  Piping  AP 

The  one  issue  that  was  not  resolved  ver:l 
successfully  during  the  development  of  Version 
1.1  of  the  3D  Piping  IGES  AP  was  how  to  handle 
the  passing  of  models  for  components,  especially 
standard  library  representations  or  catalogs. 

In  the  SEAWOLF  Piping  Data  Exchange 
efforts,  both  the  participating  shipyards  agreed  to 
exchange  material  catalogs  on  a  regular  (monthly) 
basis,  and  to  cross-reference  each  other's  part 
numbers.  Thus,  the  IGES  files  exchanged  for 
piping  merely  referenced  a  part  number  for  each 
component,  and  provided  a  transformation  matrix 
to  orient  it  correctly  in  space.  It  was  assumed  that 
the  receiving  system  would  recognize  the  part 
number  in  its  catalog,  have  the  component's 
geometry  already  loaded,  and  be  able  to  orient  the 
fitting  correctly  by  applying  the  transformation 
matrix  to  a  standard  set  of  rules  agreed  upon  for 
the  origin  and  orientation  of  all  components. 

This  approach  was  not  deemed  practical  by  the: 
developers  of  the  3D  Piping  IGES  AP  because  one 
could  not  rely  on  a  transfer  only  being  successful 
if  entire  catalogs  were  exchanged  between 
competitive  CAD  systems.  Furthermore, 
discussions  among  the  participants  about  catalog 
exchanges,  often  bogged  down  with  issues  about 
proprietary  internal  representations,  or  using 
configurations  that  were  much  more  easily 
implemented  on  one  CAD  system  than  on  another. 

The  eventual  solution  agreed  upon  for  Version 
1  .1  was  to  not  pass  catalogs,  but  instead  to  pass  ;i 
CSG  (Constructive  Solid  Geometry) 
representation  for  each  component  whenever  it 
occurred  in  the  piping  model.  Although  this 
method  was  inefficient,  it  at  least  provided  an 
interim  solution  that  would  enable  development 
and  implementation  of  the  AP  to  continue. 

A  working  group,  headed  by  NIDDESC,  is 
currently  developing  a  second  version  of  the  3D 
Piping  IGES  Application  Protocol  which  will 
address  the  catalog  issue.  The  decision  was  mad,: 
to  Classify  all  fittings  as  either  "specialty"  or 
"commodity"  components.  "Specialty"  items  will 
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be  transferred  individually  with  CSG  solid  IGES 
representations,  as  in  the  Version  1.1  solution. 

Most  standard  components  will  be  classed  as 
“commodity”  items.  The  working  group  in 
determining  a  neutral  representations  as  far  as 
origin  and  orientation  for  these  fittings.  The 
geometry  will  be  passed  as  a  parameterized  list  of 
key  dimensions  which  will  enable  the  component 
to  be  modelled  on  the  receiving  system  in 
whatever  form  that  CAD  system  uses  for  the  given 
type  of  fitting.  This  solution  will  greatly  simplify 
the  processing  of  component  data,  and  should 
make  Version  2  of  the  3D  Piping  IGES  AP  a  much 
more  easily  implemented  and  valuable 
specification. 

Several  other  enhancements  will  also  be 
included  in  this  version  of  the  Piping  AP.  The 
attribute  lists  will  be  expanded  to  permit  transfer 
of  further  information,  which  will  support 
additional  downstream  applications. 

A  new  IGES  entity,  called  Piping  Plow 
Associativity,  has  been  approved  by  the 
IGES/PDES  Organization,  and  will  be 
incorporated  in  Version  2  of  the  AP  as  a  better 
way  to  indicate  groupings  and  properties  of  piping 
collections  such  as:  Pipe  Runs,  Pipelines,  Piping 
Assemblies,  or  Piping  Systems. 

It  is  also  hoped  that  during  implementation  of 
Version  1. 1  problems  or  difficulties  may  be 
revealed  so  that  the  developers  of  Version  2  will 
be  able  to  find  improved  solutions. 

The  proposed  schedule  is  to  complete  a  draft  of 
Version  2  of  the  3D  Piping  IGES  AP  by  the  end  of 
1992,  and  then  submit  it  to  the  I.  F.  0.  for 
approval  and  incorporation  into  the  IGES 
Specification.  ^ 


Conclusions  from  Piping  AP  Efforts 

The  3D  Piping  IGES  Application  Protocol  is 
providing  a  workable  method  for  transferring 
piping  product  model  data  in  today’s  environment. 
Version  2  will  be  available  shortly,  and  this  will 
greatly  simplify  the  problem  of  passing  catalogued 
components,  and  thus  enhance  the 
implementability  of  the  document.  Eventually, 
the  3D  Piping  IGES  AF  will  be  supplanted  by  a 
STEP  application  protocol  for  the  transfer  of 
piping  product  models  (which  NIDDESC  is  also 
developing),  but  in  the  interim,  the  IGES  AP  is 
providing  industry  with  a  valuable  tool. 


THE  ENGINEERING  DRAWINGS  IGES 
APPLICATION  PROTOCOL 

Background  of  the  Drawing 

To  convey  knowledge  about  a  product’s  design 
or  fabrication,  engineering  drawings  arc  the  most 
commonly  used  tools.  One  of  the  principal  uses  ! 
most  Computer  Aided  Design  (CAD)  systems  is 
the  creation  and  production  of  these  drawing:. 
The  use  of  a  CAD  system  can  significantly 
increase  the  quality  of  drawings  produced  while 
reducing  the  time  spent  on  their  generation 
Because  of  this  double  benefit,  drawings  produced 
on  CAD  are  becoming  a  necessary  part  of  today’s 
business  environment,  including  shipbuilding. 

Since  drawings  are  used  at  various  stages  in  the 
life-cycle  of  a  product,  and  specific  stages  of  the 
life-cycle  are  usually  handled  by  different 
organizations,  it  is  likely  that  an  electronic 
drawing  will  be  represented  on  several  different 
CAD  systems  throughout  its  existence.  This  is  due 
to  the  multitude  of  systems  available,  and  their 
unique  uses  during  the  design,  fabrication  and 
support  of  a  product.  Assuming  one  wants  a 
particular  drawing  resident  on  each  of  the  CAD 
systems  involved,  one  must  either  load  the 
drawing  from  scratch  on  each  system  or  find  some 
Way  of  electronically  transferring  the  drawing 
data  from  one  system  to  another. 

Loading  the  drawing  from  scratch  is  a  time 
consuming  process,  and  it  is  prone  to  error  since  a 
considerable  amount  of  manual  work  is  involved 
Therefore,  electronic  transfer  is  a  much  preferred 
alternative.  Eor  drawing  data,  the  transfer  can 
either  be  in  rastor  or  vector  form.  Rastor  transfer 
is  best  likened  lo  faxing  a  document,  in  that  the 
image  is  broken  up  into  a  series  of  dots  which 
produce  a  picture  of  the  drawing.  This  method  is 
purely  a  two  dimensional  transfer,  and  the 
receiver  cannot  easily  modify  the  drawing.  Rasto- 
transfer,  however,  may  be  useful  where  the 
receiving  system  need  not  modify  the  data,  such  a.: 
plan  file  or  manufacturing  activity. 

When  modification  of  the  received  drawing,  or 
the  transfer  of  an  associated  model,  is  required 
then  a  vector  transfer  is  called  for.  A  vcci 


2  Development  of  the  3D  Piping  IGES 
Application  Protocol  is  being  led  by  Dr.  Burton 
Gischner  of  General  Dynamics/Electric  Boa: 
Division,  and  he  can  be  contacted  at: 

(203)  433-3948. 


5B2-7 


transfer  preserves  specific  entity  types  as  well  as 
spataial  releationship  Thus  a  three  dimensional 
ellipse  in  the  sending  system  should  result  in  a 
three  dimensional  ellipse  in  the  receiving  system. 
A  perfect  vector  transfer  would  result  in  exactly 
identical  copies  of  the  drawing,  and  any  associated 
model,  on  both  the  sending  and  receiving  systems. 
This  lofty  goal  is  seldom  reached,  although, 
perfectly  acceptable  results  are  achieved  using  the 
methods  outlined  in  this  paper. 

Assuming  a  vector  transfer  is  required,  the 
next  consideration  is  whether  to  use  a  direct 
translator  or  a  neutral  file  specification.  The 
direct  translator  takes  the  oonstruots  of  the  sending 
system  and  converts  them  to  the  constructs  of  the 
receiving  system.  Such  an  approach  may  be  useful 
when  the  translation  is  to  be  a  singular  event 
involving  two  specific  CAD  systems  with  no 
changes  to  software  revisions  during  the  process. 
If  these  conditions  are  not  met,  then  the  number  of 
direct  translators  required  increases  rapidly, 
thereby  losing  any  potential  savings.  In  this  case, 
which  is  more  common,  then  a  neutral  file 
transfer  is  called  for. 

In  a  neutral  file  transfer,  the  drawing  data  on 
the  sending  system  is  converted  to  a  neutral 
representation  which  is  then  read  into  the 
receiving  system.  The  file  can  be  transferred 
between  systems  using  magnetic  tape  or 
telecommunications  lines.  Both  the  sending  and 
receiving  systems  must  have  converters  capable  of 
understanding  both  the  neutral  file  and  the  native 
CAD  database.  Perhaps  the  most  common  neutral 
file  transfer  for  engineering  drawings  is  IGES. 
The  remainder  of  this  paper  deals  with  how  IGES 
is  being  successively  refined  to  enable  the 
successful  transfer  of  engineering  drawings. 

Drawing  Exchange  Using  Straight  TORS 

Under  continual  development  for  the  past 
twelve  years,  IGES  is  a  collection  of  neutral 
representations  for  geometric,  annotation  and 
organizational  entities  needed  to  make  up 
drawings  with  some  product  model  data.  These 
entities  are  grouped  together  in  a  fixed-format 
text  file  which  a  sending  processor  creates  from 
the  native  CAD  database.  The  file  is  then 
transferred  to  the  receiving  processor  which  reads 
the  file  and  converts  the  IGES  entities  to  native 
database  entities  and  constructs.  Specific 
information  about  the  actual  IGES  file  may  be 
found  in  "Reference  1." 

All  of  the  constructs  necessary  to  build  an 
electronic  engineering  drawing  are  present  in 


IGES.  This  includes  not  only  geometry  and 
annotation,  but  also  items  such  as  views, 
coordinate  systems,  line  styles  and  subfigures. 
The  problem  with  IGES,  in  fact,  is  that  many  of 
the  necessary  constructs  may  be  represented 
several  ways.  As  an  example,  there  are  two 
distinct  ways  to  represent  splints  in  an  IGES  file, 
parametric  or  rational  b-splinc.  This  leads  to 
problems  when  the  sending  system  outputs  one 
type,  and  the  receiving  system  is  set  to  receive  the 
other.  Both  systems  are  correct,  yet  the  data  will 
not  be  transferred. 

After  organizations  spent  several  years 
attempting  to  transfer  data  with  the  mismatches 
described  above,  a  consensus  was  reached  among 
IGES  users  that  some  refinement  of  the  process 
was  necessary  for  successful  data  exchange  to  take 
place.  Since  all  of  the  IGES  constructs  were 
necessary  lo  some  users,  condensing  the  actua. 
Specification  was  not  practical.  Thus,  some 
projects  placed  limits  on  how  IGES  could  be  used 
for  a  given  transfer.  Three  of  these  are  described 
below,  for  these  should  be  considered  the 
forerunners  of  the  application  protocol. 

Project  Peculiar  Uses  Of  IGES 

One  of  the  largest  driving  forces  behind  IGES 
has  been  the  U.S.  Department  of  Defense  (DoD) . 
As  many  weapons  systems  have  been  designed  and 
fabricated  with  IGES  transfers  as  part  of  the 
process,  DoD  has  a  vested  interest  in  establishing 
successful  IGES  transfers.  To  promote  this  goal, 
DoD  has  issued  a  military  specification, 
MIL-D-28000  (2),  which  requires  the  use  of 
subsets  of  IGES  for  various  applications.  One  of 
these  is  the  transfer  of  engineering  drawings, 
which  is  the  Class  II  subset.  A  subset  restricts  the 
type  of  IGES  entities  that  may  be  used  for  a 
particular  application,  with  the  entities  coming 
from  the  entire  specification.  No  guidance  is 
given  as  to  how  the  entities  will  be  used,  which 
leads  to  problems  when  them  are  multiple  ways  to 
use  the  same  entity.  Because  of  this,  the  subset  is 
not  used  in  production,  and  the  goal  of  the  project 
team  developing  the  AP  is  lo  replace  Class  II  with 
the  AP. 

Since  a  combination  of  entity  restrictions  and 
usage  guidelines  is  required  to  successfully 
implement  an  IGES  transfer,  it  would  be  a  great 
advantage  if  both  the  sending  and  receiving 
systems  were  known  before  the  transfer  capability 
is  developed.  Such  was  the  case  for  the 
representatives  of  the  Navy,  the  Electric  Boat 
Division  of  General  Dynamics  and  Newport  News 
Shipbuilding  who  implemented  the  SEAWOLF 
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Digital  Data  Exchange.  The  SEAWOLF 
submarine  is  a  joint  design  project  between  the 
three  organizations,  and,  from  the  outset,  an 
electronic  drawing  exchange  capability  was 
desired  to  support  the  project.  IGES  was  chosen 
as  the  transfer  mechanism,  and  Computervision 
and  Cadam  were  the  CAD  systems  involved. 

Because  the  SEAWOLF  exchange  was  bounded 
as  described  above,  intensive  testing  was 
conducted  to  establish  an  acceptable  transfer 
capability.  This  involved  considerable  rework  to 
both  IGES  processors,  identification  of  specific 
entities  and  constructs  to  be  used,  and  the 
generation  of  a  set  of  specific  procedures  to  be 
used  for  the  exchange.  The  exchange  is  based  on 
functional  equivalence  between  sending  and 
receiving  systems,  so  while  transmitted  drawings 
may  not  look  exactly  alike,  they  will  still  be 
completely  usable.  An  example  of  this  is  that 
block  letters  may  be  filled  on  one  system,  and  in 
outline  form  on  the  other.  The  letters  arc  still 
readable  on  both  systems.  This  exchange  is 
currently  in  production;  the  key  to  this  was  the 
establishment  of  a  set  of  specific  project 
information  to  use  for  the  exchange.  For  more 
information  on  the  SEAWOLF  program,  please 
see  “Reference  5.” 

The  U.S.  Department  of  Energy  (DoF)  took 
the  idea  of  project  specific  exchange  documents 
one  step  further.  For  their  sites  involved  in 
nuclear  work,  DoF  developed  a  plan  for  the 
exchange  of  drawing  data  amongst  the  CAD 
systems  involved.  Again  this  plan  was  IGES 
based,  and  the  exchange  was  bounded  by  the 
involved  systems.  This  project,  known  as  the 
DOEDEF  (Department  of  Energy  Data  Exchange 
Format)  was  planned  around  an  agreed  to  level  of 
exchange  capability,  which  was  tested  before 
actual  production  exchanges.  Also,  key  to  this 
program  was  the  development  of  project  specific 
instructions,  including  what  entities  and  constructs 
could  be  used.  This  project  involved  more  than 
two  CAD  systems,  so  the  testing  and 
documentation  was  even  more  involved  than  that 
required  for  SEAWOLF. 

What  the  three  projects  described  above  all 
point  to  is  that  for  IGES  exchange  to  work  both 
entity  constructs  and  specific  usage  instructions 
are  required.  Although  the  problem  is  simplified 
if  the  sending  and  receiving  systems  are  loiown, 
this  is  not  always  the  cast.  Therefore,  a  more 
comprehensive  document  is  required  to  guarantee 
an  acceptable  level  of  IGES  drawing  exchange. 
The  answer  to  this  need  is  ant  application  protocol, 
AP,  which  defines  how  IGES  can  be  used  for  « 
specific  discipline  exchange,  in  this  case 


engineering  drawings.  By  having  CAD  systems, 
and  their  users,  agree  to  produce  and  receive 
IGES  files  in  a  certain  way.  an  acceptable  transfer 
can  be  assured.  Thus,  an  AP  is  a  project  specific 
document  applying  to  the  entire  class  of  IGES 
drawing  exchange.  The  rest  of  this  paper  traces 
the  development  of  an  AP  for  engineering 
drawings. 

Engineering  Drawing  IGES  AP 
Development 

As  stated  above,  an  AP  for  engineering 
drawings  covers  an  IGES  exchange  between  any 
combination  of  users  and  systems  that  state  they 
produce  AP  compliant  files.  Therefore,  the 
logical  group  to  develop  such  a  document  is  a 
combination  of  CAD  vendors  and  users.  The 
IGES/PDES  Organization  recognized  such  a  need 
and  directed  the  I.P.O.  Drafting  Committee  to  put 
together  such  a  group  and  produce  an  AP. 

Early  efforts  centered  around  an  AP  to  govern 
the  exchange  of  drawings  that  arc  purely  two 
dimensional,  with  no  associated  product  model. 
As  development  proceeded  on  this  protocol,  it 
became  evident  that  this  class  of  exchange  was 
really  a  subset  of  the  broader  category  of 
exchange  of  drawings  with  an  associated  model. 
Therefore,  this  project  was  rolled  into  the 
comprehensive  protocol  which  is  under  activ 
development. 

To  efficiently  produce  the  protocol,  the  L.P.O. 
Drafting  Committee  formed  a  specific  project 
devoted  to  this  document.  The  project  is  chaired 
by  Mr.  G.  Morea,  who  is  sponsored  by  NIDDESC 
The  Navy  actively  endorses  the  IGES  protocol 
concept,  and  NIDDESC  expects  this  protocol  to 
replace  the  Class  II  subset  in  MIL-D-28000  (2). 
The  I.P.O.  project  includes  members  of  both  the 
vendor  and  user  communities.  Representatives 
from  Caterpillar  and  Sandia  National 
Laboratories  have  been  especially  active  from  the 
user  community.  Likewise,  representatives  form 
Computervision  and  Autodesk  have  been  active 
from  the  vendor  community.  Both  the  users  and 
vendors  realize  that  a  successful  protocol 
implementation  will  require  input  from  both 
parties.  Working  under  the  Drafting  Committee, 
the  project  group  meets  regularly  to  develop  the 
document.^ 

^  Development  of  the  Engineerings  Drawing 
IGES  Application  Protocol  is  being  led  by  Mr. 
Gregory  Morea  of  General  Dynamics/Electric 
Boat  Division,  and  he  can  be  contacted  at: 

(203)  433-3403. 
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Again,  there  are  several  different  combinations 
of  drawings  and  models  that  need  to  be  exchanged, 
depending  on  specific  project  needs.  To 
accommodate  this^  the  protocol  has  established  a 
taxonomy  of  engineering  drawing  creation  and 
exchange  parameters.  As  examples^  there  may  or 
not  be  an  associated  models  and  the  dimensions 
may  or  may  not  be  associated  with  features  of  the 
model.  Depending  on  how  these  parameters  arc 
set^  certain  levels  of  exchange  functionality  are 
defined.  These  range  from  the  exchange  of  two 
dimensional  sketches  to  the  exchange  of  a  model 
alone  from  which  a  drawing  is  automatically 
produced  on  the  receiving  system. 

To  support  each  of  the  defined  levels  of 
functionality,  a  set  of  application  requirements  is 
defined.  'These  specify  the  constructs  that  both  the 
users  and  vendors  must  use  to  produce  compliant 
files.  A  reference  model  organizes  this  data  from 
a  logical  standpoint,  and  an  interpreted  model 
provides  the  specific  IGES  entities  and  constructs 
to  be  used  in  file  creation.  This  protocol  uses  the 
same  reference  model  as  STEP  AP  202^ 
Associative  Draughting.  As  STEP  is  the  logical 
progression  from  IGES,  this  protocol  provides  a 
bridge  between  the  two.  In  addition,  data 
generated  from  this  protocol  will  be  used  to 
further  validate  AP  202  as  it  is  developed. 

Accompanying  the  protocol  itself  is  a  large 
body  of  test  data.  This  data  serves  two  specific 
purposes.  The  first  is  to  validate  the  ideas  and 
constructs  specified  in  the  protocol  itself.  The 
second  is  to  provide  a  baseline  for  users  and 
vendors  to  use  when  assessing  compliance  to  the 
protocol.  The  test  data  is  a  combination  of 
specially  developed,  protocol  specific  cases  and 
actual  user  drawings. 

To  obtain  the  support  that  the  protocol  needs 
for  effective  implementation,  it  will  go  through  a 
number  of  formal  approval  cycles  before  being 
published.  The  I.P.O.  Drafting  Committee, 
Application  Validation  Methodology  Committee 
and  IGES  Project  Committee  all  need  to  approve 
the  document  before  the  entire  I.P.O.  approves  it. 
Once  this  is  accomplished,  the  document  will  be 
published  both  as  part  of  the  IGES  Specification 
(1)  and  as  part  of  MIL-D-28000  (2).  At  this  point, 
the  protocol  can  be  used  to  successfully  transfer 
engineering  drawing  data  within  the  IGES 
community. 

Conclusions  from  Drawing  AP  Efforts 


exchange  capability  that  can  be  guaranteed 
independent  of  specific  vendor  user  combinations 
by  specifying  a  protocol  compliant  file. 

This  climates  the  need  for  rounds  of  testing 
now  required  each  time  a  project  seeks  to  use 
IGES  for  drawing  transfer.  In  addition,  this 
reduces  the  errors  associated  with  attempts  to  use 
the  entire  specification.  The  document  also 
provides  an  ideal  transition  to  STEP. 

SUMMARY 

The  eventual  goal  for  data  transfer  is  to  uset. 
neutral  file  solution  incorporating  STEP,  the 
international  standard  for  product  model 
exchange,  but  the  reality  of  this  is  several  years 
away.  Thus,  NIDDESC  has  led  the  development 
of  two  IGES  application  protocols  to  provide  an 
interim  method  for  transfering  piping  product 
models  and  engineering  drawings  via  IGES  before 
the  completion  of  STEP. 

These  application  protocols  provide  valuable 
data  exchange  tools  now,  and  will  provide  a 
baseline  and  guideline  for  the  development  of 
STEP  application  protocols.  They  will  be  the  first 
application  protocols  submitted  to  the  I.  P.  0.  for 
approval,  and  are  setting  a  precedent  for  future 
developments . 

The  IGES/PDES  Organization  has  agreed  to 
include  all  approved  application  protocols  as  part 
of  the  IGES  Specification,  and  MIL-D-28000  will 
reference  these  documents  so  they  can  be  invoked 
on  DoD  contracts.  Thus,  by  guiding  development 
of  the  3D  Piping  IGES  Application  Protocol  and 
the  Engineering  Drawings  IGES  Application 
Protocol,  NIDDESC  has  taken  the  lead  in 
providing  national  standards  to  enable  production 
exchange  of  this  data  in  today's  environment. 
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